Happy Git and Github for the useR
Session 05 - Git Remote Setups + Daily Workflows

Boook club R-Ladies Bergen, R-Ladies Den Bosch, R-Ladies Amsterdam

Kylie Ainslie

Program for today

  • Remote Setups
    • 25 Common remote setups
  • Daily Workflows, Part 1
    • 27 The Repeated Amend
    • 28 Dealing with push rejection
    • 29 Pull, but you have local work

Chapter 25: Common remote setups

Recap

  • A remote is repository hosted elsewhere than your local machine (e.g., on GitHub)
    • The remote is named origin or upstream.
    • On GitHub a remote URL looks like
      • https://github.com/OWNER/REPO.git or
      • git@github.com:OWNER/REPO.git

Recap

Recap

Recap

  • A fork is a copy of a repository on a remote server (e.g., GitHub)
  • A clone is a copy of a repository on your local machine

No GitHub

  • To create a local Git repo:
    • git init
    • usethis::use_git()
    • In RStudio:
      • Existing Project: Tools > Version Control > Project Setup
      • New Project: Make sure “Create a Git repository” is selected

Yours

  • A remote named origin is configured with permission to push/pull.
  • origin on GitHub is a source repo.
  • origin is your primary repo.

Yours - setup

  • If the local repo exists first:
  • If the remote repo exists first:
    • For detailed instructions see New RStudio Project via git clone.
    • usethis::create_from_github("OWNER/REPO", fork = FALSE).
    • Command line: git clone <URL>
    • RStudio: File > New Project > Version Control > Git

Ours

  • origin is a source.
  • origin is your primary repo.
  • How to achieve?
    • same as above, but specify usethis::use_github(organisation = "ORGNAME").

Theirs

  • How does this setup happen?

  • Cloning the source repo (via git clone <URL> or Git client)

  • usethis::create_from_github("OWNER/REPO", fork = FALSE).

  • What if you do want to make a pull request?

    • Should have done fork-and-clone instead of clone.

Fork (of theirs)

  • You have a fork (origin) of the source repo (upstream).
  • Your local repo can pull (not push) changes from upstream.
  • origin is your primary repo (push/pull permission).
  • You can make a pull request back to the source repo via your fork.

Fork (of theirs) - setup

  • Detailed instructions are given in Fork and clone.
  • usethis::create_from_github("OWNER/REPO", fork = TRUE).
  • Command line Git or RStudio: You can’t complete this task fully

Fork (of ours)

  • Offers maximum flexibility for advanced users
  • How to achieve?
    • Same as the regular fork setup above.
    • usethis::create_from_github("OWNER/REPO", fork = TRUE).

Fork (salvageable)

  • How does this happen?
    • Cloning your own fork, then stopping there.
  • Convert into the fork setup above:
    • For detailed instructions see Finish the fork and clone setup.
    • Add source repo as the upstream remote.
    • Set upstream/main as the upstream tracking branch for local main.

Daily workflows, part 1

Chapter 27: The repeated amend

Recap

  • A commit is a snapshot of your project at a particular point in time.
    • It captures changes made to files and records them in the version history.
    • git commit
  • Amend is used to rewrite the last commit (e.g., update commit message or files).
    • git commit --amend
    • Allows fixing minor issues without creating a new commit

Mountain Climbing Analogy

Think of your project as a mountain you’re climbing.

Mountain Climbing Analogy

Coding without commits is like free-climbing:

  • faster in the short-term, but
  • higher chance of catastrophic failure long-term

Mountain Climbing Analogy

Using a commit is like using anchors when climbing.

Mountain Climbing Analogy

If you make a mistake, you can’t fall past the previous commit

[Image placeholder]

When to Use Amend

  • If you made a minor error or forgot to add files
  • If you need to update the commit message
    • git commit --amend
    • RStudio makes it very easy

Potential Pitfalls

  • Amending after pushing:
    • You should avoid amending commits that have already been pushed to a shared repo
    • Amending pushed commits rewrites history and can cause problems for collaborators
    • Use with caution when working on shared repositories

Workflow - Step 1

Start with your project in a functional state. - Use git status to check this.

Workflow - Step 2

::: aside Initial status of project. :::

Workflow - Step 2

** Don’t push!**

Workflow

  1. Get to work
  • Do a bit more work.
  • Re-check that your project is still in a functional state.
  • Stage and commit again, but this time amend your previous commit.
    • git commit --amend --no-edit

** Don’t push!**

Workflow

  1. Get to work
  • Keep going until you’ve achieved your final objective.
  • Now ammending the commit, but add a real message
    • git commit --amend -m "Implement awesome feature"
  • Push the changes: git push

Workflow

  1. What if I need to fall back?
  • Imagine you’re in the middle of a Repeated Amend workflow and you make some changes that break your project:
A -- B -- C -- WIP* 
  • You want to fall back to the last good state, represented by WIP*.
    • This is called a hard reset to the WIP* state.
    • Meaning: “reset my files to their state at the most recent commit”.
  • How to achieve?
    • command line: git reset --hard
    • RStudio:
      • Click on “Diff” or “Commit”.
      • Select a file with changes you do not want.
      • Use “Discard All” to discard all changes in that file.
      • Use “Discard chunk” to discard specific changes in a file.

Workflow

  1. What if I did push?

Let’s imagine you pushed this state to GitHub by mistake:

A -- B -- C -- WIP (85bf30a)

and proceeded to git commit --amend again locally, leading to this state:

A -- B -- C -- WIP* (6e884e6)

Workflow

  1. What if I did push?

You have two choices:

  1. You’re working with collaborators:
  • Save a copy of any files that exist locally (with changes) to a new file path, temporarily.
  • Hard reset your local repo to C (git reset –hard HEAD^) and pull from GitHub.
A -- B -- C -- WIP (85bf30a)
  • Bring any files saved temporarily elsewhere back into the repo now; save, stage, commit, and push.
A -- B -- C -- WIP (85bf30a) -- E

Workflow

  1. What if I did push?

You have two choices:

  1. You have no collaborators:
  • Make sure your local commit has a real, non-“WIP” message.
  • Force push your history to GitHub (git push --force).
A -- B -- C -- D

The end of the session 5!